Every plant has one. A Windows box sitting in a cabinet somewhere, running a VPN client that terminates a tunnel straight from an integrator’s laptop in another country into the same flat Level 2 network as the HMIs and the historian. Nobody remembers exactly when it was installed. IT doesn’t manage it. Controls doesn’t want to touch it because “that’s how the OEM gets in for support.” It works, until it’s the reason a ransomware operator is inside your process network at two in the morning.
That scenario is not hypothetical anxiety. It is the pattern CISA keeps describing in its ICS advisories: initial access through exposed or credential-weak remote access services, not zero-days in PLC firmware. The unglamorous truth about OT compromise is that attackers mostly don’t need to be clever. They need a VPN endpoint with no multi-factor authentication, a shared password an integrator has used since commissioning, or a tunnel that drops a remote user straight onto the plant network with no segmentation on the other side. Flat VPN access has become the dominant initial-access vector precisely because it was built for convenience, not containment.
Why “just use a VPN” stopped being good enough
A traditional site-to-site or client VPN answers one question: is this connection encrypted and authenticated at the perimeter? It says nothing about what that connection is allowed to touch once it’s inside, what the remote user actually does during the session, or whether the credential being used still needs to exist tomorrow. That’s the architectural gap. VPN grants network-layer access; it doesn’t grant scoped, auditable, time-bound access to a specific asset for a specific purpose. In an OT environment where a compromised engineering workstation can mean a compromised safety instrumented system, that gap is the whole ballgame.
This is also exactly what IEC 62443-3-3 is trying to force plants to reckon with. The standard’s system requirements around identification and authentication control (SR 1.x), use control (SR 2.x), and particularly the requirements touching remote access sessions don’t say “install a VPN.” They ask whether the system can enforce least privilege, whether sessions can be monitored and terminated, whether remote access is explicitly authorized rather than persistently available, and whether accountability can be tied to an individual, not a shared service account. A flat VPN with a static password satisfies none of that on its own, no matter how strong the encryption is. Auditors doing vendor onboarding under a 62443-aligned purchasing gate are increasingly asking plants to produce evidence, not assurances, that this control exists.
What brokered zero-trust access actually changes
The architecture practitioners are converging on isn’t exotic. It’s a remote access broker, sometimes called a secure remote access gateway or jump host architecture, sitting between the outside world and the OT network, with a few properties a flat VPN doesn’t have:
- No direct network reachability. The remote user or vendor never gets an IP address on the OT VLAN. They authenticate to a broker, which then proxies a specific application session — an RDP session to one engineering workstation, an HTTPS session to one HMI — to a specific destination.
- Just-in-time credentials. Access is requested, approved, and provisioned for a bounded window, then revoked automatically. Nobody is carrying a VPN credential that still works six months after the commissioning project ended.
- Session recording and live monitoring. Every remote session is logged, and in many implementations recorded as video or keystroke capture, so plant security staff can review exactly what a vendor did, and shut the session down in real time if something looks wrong.
- Identity tied to a person, not a shared account. Multi-factor authentication and individual accountability replace the one shared VPN login that three different OEM technicians have used for years.
Map that against 62443-3-3 and the SR-to-control alignment is direct: individual authentication satisfies identification and authentication requirements far more cleanly than a shared VPN credential ever could; session termination and monitoring capabilities map to use control and audit requirements; the elimination of standing network access maps to the standard’s zone-and-conduit segmentation intent far better than a VPN tunnel that dead-ends inside the zone it’s supposed to be protecting.
The OEM objection, and how to actually resolve it
The predictable pushback comes from integrators and machine builders who’ve supported the line the same way for a decade: “give us the VPN drop, we’ll be in and out in twenty minutes.” That objection is worth taking seriously rather than steamrolling, because a plant that makes remote support painful will get slower support, and slower support during a line-down event is its own risk.
The resolution isn’t to refuse vendor access. It’s to make brokered access easier for the vendor than the VPN ever was. A well-configured access broker gives the OEM a single portal, a request-and-approve workflow that can take minutes, and a session that opens directly to the one HMI or PLC programming station they need — no VPN client to install, no split-tunnel configuration to argue about, no static credential to manage on their end. Most integrators, once they’ve used it once, prefer it, because it removes their own liability for holding a standing credential into your network. The ones who genuinely insist on flat network access as a non-negotiable are worth pushing back on directly, and worth flagging as a supplier risk in your own vendor management documentation.
Where to actually start
Don’t try to migrate every remote path on day one. Inventory every existing remote access method into the OT environment first — you will find more than you expect, including things IT never provisioned. Rank them by criticality of the asset behind them and by how loosely controlled the credential is. Put the broker in front of the worst offender first, typically the always-on VPN with a shared password reaching a safety-adjacent system, and use that as the proof point for both the OEM relationship and the audit file. The architecture change matters, but the sequencing is what actually gets it done without a production outage or a vendor revolt.
The pattern in the advisories isn’t subtle anymore. Attackers go through the door that’s already unlocked, and for a lot of OT networks that door is still a VPN nobody has re-evaluated since it was installed. Fixing that isn’t a compliance exercise you do for the auditor. It’s the actual difference between an incident that stays contained and one that doesn’t.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
